• src/shared/api/study-api/study-api.ts

eslint.config.js (1)

143-154: ⚡ Quick win

Consider adding custom error messages for each zone restriction.

Adding a message property to each zone would provide clearer feedback when developers accidentally violate the architectural boundaries.

💬 Suggested enhancement with custom messages

 'import-x/no-restricted-paths': [
     'error',
     {
         zones: [
             // shared must not import from features or app
-            { target: './src/shared', from: './src/features' },
-            { target: './src/shared', from: './src/app' },
+            { 
+                target: './src/shared', 
+                from: './src/features',
+                message: 'Shared modules cannot import from features. Shared must remain dependency-free.'
+            },
+            { 
+                target: './src/shared', 
+                from: './src/app',
+                message: 'Shared modules cannot import from app. Shared must remain dependency-free.'
+            },
             // features must not import from app
-            { target: './src/features', from: './src/app' },
+            { 
+                target: './src/features', 
+                from: './src/app',
+                message: 'Features cannot import from app. Move shared logic to features or shared layers.'
+            },
         ],
     },
 ],

The rule syntax is compatible with eslint-plugin-import-x v4.16.2 and the zone configuration format is properly supported.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@eslint.config.js` around lines 143 - 154, The import-x/no-restricted-paths
rule currently blocks imports between zones but omits human-friendly messages;
update the zones array used by 'import-x/no-restricted-paths' to add a message
string to each zone object (e.g., the entries with target './src/shared' from
'./src/features' and './src/app', and the entry with target './src/features'
from './src/app') so ESLint reports a clear, custom error when a developer
violates these architectural boundaries; keep the existing targets and from
fields and only add concise, actionable 'message' values explaining why the
import is disallowed.

src/app/config/app-config.ts (1)

11-11: 💤 Low value

Remove unnecessary type assertion.

The selectToken function signature (state: StateWithAuthentication) => string | undefined is compatible with TokenSelector = (state: unknown) => string | undefined due to TypeScript's structural subtyping (contravariance on parameter types). The as TokenSelector assertion is unnecessary and could mask future signature drift.

♻️ Simplify to implicit type compatibility

-configureParams({ appName: APP_NAME, tokenSelector: selectToken as TokenSelector });
+configureParams({ appName: APP_NAME, tokenSelector: selectToken });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/app/config/app-config.ts` at line 11, The code currently uses an
unnecessary type assertion on selectToken when calling configureParams; remove
the "as TokenSelector" cast so the call becomes configureParams({ appName:
APP_NAME, tokenSelector: selectToken }); this relies on TypeScript's structural
typing and avoids masking future signature drift—update the call site that
references configureParams, APP_NAME and selectToken accordingly.

src/app/providers/AppProviders.tsx (1)

19-20: ⚖️ Poor tradeoff

Fragile module initialization order dependency.

The side-effect import on line 19 must execute before line 20 because:

1. app/config/app-config calls configureParams(...) at module load
2. app/store/store creates the store (line 31) and calls updateConfigParams({ store }) (line 33)
3. updateConfigParams will throw if configureParams hasn't been called first

This ordering is correct but fragile—swapping these imports would cause a runtime error. The ES module specification guarantees import order, but this implicit dependency is easy to break during refactoring.

Consider making initialization explicit:

• Move configureParams call to an exported initialization function in app-config.ts
• Call it explicitly from an app entry point before importing the store
• Or use a lazy store initialization pattern

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/app/providers/AppProviders.tsx` around lines 19 - 20, The current
side-effect import of app/config/app-config (which runs configureParams at
module load) is a fragile implicit dependency for app/store/store (which creates
store and calls updateConfigParams); refactor to make initialization explicit by
exporting a setup function (e.g., initAppConfig or configureParamsExplicit) from
app-config that performs configureParams, then call that setup from a single app
entry point before any import/use of store or useAppSelector, or alternatively
implement a lazyStore initializer inside app/store/store that defers store
creation until after configureParamsExplicit is called; update references to
configureParams, app-config, store, useAppSelector, and updateConfigParams
accordingly so initialization order is enforced explicitly rather than relying
on side-effect import order.

src/features/authentication/store/authentication.selectors.ts (1)

12-12: 💤 Low value

Consider adding explicit return type for clarity.

While TypeScript correctly infers string | undefined, adding an explicit return type improves readability and prevents unintended signature changes, especially since this selector is used as a TokenSelector in the centralized configuration.

📝 Add explicit return type

-export const selectToken = (state: StateWithAuthentication) => selectUser(state)?.id_token;
+export const selectToken = (state: StateWithAuthentication): string | undefined => 
+    selectUser(state)?.id_token;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/features/authentication/store/authentication.selectors.ts` at line 12,
The selector selectToken currently relies on inferred return type; update its
signature to include an explicit return type (e.g., string | undefined) to match
the TokenSelector expectation and avoid accidental signature changes—modify
selectToken(state: StateWithAuthentication): string | undefined { ... } (ensure
the return type aligns with the TokenSelector used in your centralized
configuration).

src/shared/config/config-params.ts (1)

28-33: ⚡ Quick win

Validate store is not updated after initial registration.

updateConfigParams allows replacing the store reference after initialization. Since the store should only be set once (after creation in store.ts), consider preventing subsequent store updates to avoid accidental reconfigurations.

🛡️ Proposed safeguard

 export function updateConfigParams(config: Partial<ConfigParams>): void {
     if (configParams === undefined) {
         throw new Error('Config params not initialized. Call configureParams() before using modules.');
     }
+    if (config.store && configParams.store) {
+        throw new Error('Store already registered. Cannot update store reference.');
+    }
     Object.assign(configParams, config);
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/shared/config/config-params.ts` around lines 28 - 33, updateConfigParams
currently allows replacing the existing store reference which can lead to
accidental reconfiguration; modify updateConfigParams to detect when the
incoming partial config contains a store and the existing configParams.store is
already set, and in that case prevent overwriting (either by throwing an Error
or by ignoring the store field) while still applying other allowed fields via
Object.assign; refer to updateConfigParams and the configParams.store field (and
the store creation in store.ts) when making the change.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes